Discord message links - #135

- Pass issue source as &str via as_str() in verify/reply paths.
- Write rendered MCP config to the open temp handle instead of reopening
  the path (avoids Windows exclusive-lock failures).
- Validate exactly one of command/url per server; skip and warn otherwise
  so strict MCP loading never sees an ambiguous transport.
- Add per-server tools allowlist: scope to mcp__<server>__<tool> when set,
  else grant all via mcp__<server>. Lets read-only runs be scoped to read
  tools; read-only API key remains the enforced boundary.
- Example config shows read-only tool scoping; config test covers tools.

- Read-only runs (Q&A/verify/reply) no longer get unscoped MCP tools; a
  server must declare an explicit `tools` allowlist to be usable there.
  Fix runs still default to all tools. Closes the read-only-boundary gap.
- Validate transport consistency: reject `command` with a non-stdio type
  and `url` with stdio, not just presence, so --strict-mcp-config never
  sees a contradictory server. Added has_valid_transport() + tests.
- Clarify render_mcp_config doc (temp filename, 0600 is Unix-only).

Read-only runs (Q&A/verify/reply) now draw tools only from a dedicated
per-server readonly_tools list, never from `tools` (which may include
mutating tools used by fix runs). Since a tool's capability cannot be
verified at config time, the operator must explicitly list non-mutating
tools for read-only use; with none listed, read-only runs get no MCP
tools. Closes the remaining production-mutation path.

Asserts the url branch emits type/url/headers and omits stdio-only
fields (command/args/env). Addresses review coverage gap.

- Reword the strict-mcp-config comment: flags are only added when a
  config is attached; no MCP flags when nothing matches.
- Render tests read the temp file via reopen() instead of by path,
  matching render_mcp_config's Windows-safe handle write.

The API key is the access boundary, so a separate read-only tool list
added complexity without a real guarantee. Collapse to one `tools` array
(empty = all of the server's tools) applied uniformly to fix and Q&A
runs. Drop readonly_tools.

The reproduce/verify stage already produces a structured verdict
(root cause, impact, suggested fix, evidence) but it was only posted
as a note and thrown away before the fix ran. Carry it on
ProcessingInput and prepend it to the fix prompt context so the fix
agent starts from a confirmed root cause instead of re-deriving one.

Three opt-in triage guardrails from the Cloudflare/Astro triage model:

- verify_fail_open (ReplyConfig, default true): when the reproduce/
  verify stage can't run (timeout/error/unsupported), setting this
  false asks the reporter for repro steps instead of forcing a fix.
- fail_on_regression (EvaluationConfig, already existed): now wired.
  A successful attempt whose after-fix eval shows new failures or
  regressions is failed and retried instead of shipping the PR.
- request_reporter_verification (ReplyConfig, default false): after a
  PR is created, ask the original reporter to confirm the fix resolves
  the issue on their end.

Drops request_reporter_verification and the post-PR reporter ping.
Keeps the diagnosis-forwarding, verify_fail_open, and regression-gate
guardrails.

The e2e config builder constructs ReplyConfig field-by-field, so the
new verify_fail_open field must be set explicitly. Addresses greptile
review comment on PR #132.

Adds opt-in evaluation.require_red_green (default false). When enabled
and a test tool is detected:

- Red phase: before the fix, a dedicated agent run authors a failing
  test only (no app code). The eval suite is re-run against the
  baseline; if no new test failure appears, the bug isn't reproduced
  and the attempt fails.
- Fix phase: the fix prompt is told the failing test already exists
  and to make it pass without weakening it.
- Green phase: the existing after-fix eval gate is forced on in
  red-green mode, so a test still failing after the fix fails the
  attempt.

Adds EvaluationResult::has_new_test_failures() (test-category only) and
a covering unit test.

The red-green phase previously ran invisibly inside Pending. Now it
emits dedicated timeline events and issue decisions:

- RedGreenStarted when the failing-test phase begins
- RedConfirmed / red_green_not_reproduced for the red assertion
- GreenConfirmed / not_green for the after-fix assertion

Also records red_green action runs (red_confirmed / not_reproduced /
green_confirmed / not_green) so the dashboard timeline reflects each
step instead of showing only a stalled Pending attempt.